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Why this talk... 

• Game AI architectures are pretty modular 

• We used a behavior tree for the AI in Evolve 

o But the AI was still hard to get out the door 

• So we set out to fix our AI system 

o Figure out why our modular system wasn’t “modular enough” and fix it 
o Without breaking our legacy characters and the systems that run them 



How do you fail at Modular? 


Let’s start with a simple example 



Forest Troll - Tree Trunk Tornado 





Forest Troll -Tree Trunk Tornado 

• The details! 

o Should only attempt when surrounded 
o It’s a Point blank AOE attack 
o After completion, troll is “tired” 

• So we make a new node for the behavior tree 

o OnStart, it checks enough enemies close by the troll 
o Do an animated attack, play an animation, sounds, triggers damage boxes 
o On completion, sets some data on the blackboard for “tired” 

• Perfectly reasonable implementation 

o But we know what comes next 



Ok, we failed. Now what? 



Separation of Responsibility 







Details, Guidelines and our solution 



Al’s World State - the glue... 

• Game State vs World State 

• World State == Big Block O’ Data 

• Guidelines 

o Every character should be able to have their own 
o Keep this structure simple 

• Evolve splits up this concept 

o The blackboard - enumeration of game state 
o The NEW whiteboard - rich data 



Sensing 

• Where data collection happens 

• Guidelines 

o Modular and atomic 

o Characters should be able to have different sets of sensors, 
o Where the heavy lifting happens 
o Keep out of your deciding loop 

• Evolve’s New Sensor Manager 

o Allows users to install sensors per character 
o Allows sensors to have a different stale time per character type 
o Manager burns through as many sensors it can in its allotted time 



Acting 

• Acting makes up the operations that the AI actually does 

o Your attacks, reloads, interactions, etc 

• Guidelines 

o Operations should be agnostic to the reasons they are being done 
o Operations should be agnostic to the world state it references 
o Operations shouldn’t try to do more than one thing 
o Operations shouldn’t change your world state 

• Evolve’ s Acting 

o Our acting is done in our BT nodes 



Deciding 

• Where we make decisions 

o Behavior Systems (HTN, GOAP, BTs, FSM ) 

■ Kinda 

• Guidelines 

o Deciding should be fast 

o Should be able to annotate the acting components 
o Should be fast to edit. 

• Evolve uses the BT described in Bill Merril’s Game AI Pro 
article 

o Great article, go check it out 



Blueprints - making it all stick together 

• Evolve uses blueprints as a way to have one location where 
we can setup a character. 

o Load designer tunable data 
o Define the blackboard and install whiteboards 
o Install all the different components for our character 
o Connecting everything together 

• This is how we built new AI without breaking legacy AI 



Al System Layout 






Al System Layout: Behavior Tree [Evolve ] 
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Al System Layout: HTN Planner 
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Al System Layout: FSM 








In Conclusion 


• Modular system != Modular Characters 

• Think in terms of responsibilities 

• Make it easy for programmers to do the right work in the 
right place 

• You can do it! 
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